Reducing Latencies in Web Page Rendering

ABSTRACT

A page structure may be used to begin validation of an embedded resource prior to the time a browser issues a request to validate the embedded resource. A page structure includes information indicating one or more embedded resources in the web page and, in some implementations, its corresponding cache characteristics. The page structure may be used to generate a validation message that indicates resources to be validated. The validation message may be sent to a server at substantially the same time that the browser begins rendering the web page. The server can then begin validating the resources indicated in the validation message by sending validation requests to an origin or other server storing the embedded resources. The server then may send the validation responses back to the client computer executing the browser so that the validation responses can be used to satisfy corresponding validation requests generated by the browser.

CLAIM OF PRIORITY

This application is a continuation in part of U.S. patent applicationSer. No. 11/025,842, filed Dec. 30, 2004, titled “Reducing Latencies InWeb Page Rendering,” and which claims priority under 35 USC §119(e) toU.S. Patent Application Ser. No. 60/566,174, filed on Apr. 29, 2004. Theentire contents of both applications are hereby incorporated byreference.

TECHNICAL FIELD

This description relates to reducing latencies in web page rendering.

BACKGROUND

In order to speed up the experience of browsing the World Wide Web, theHTTP protocol supports the use of local caching. See “HyperText TransferProtocol-HTTP/1.1,” RFC 2616,http://www.w3.org/Protocols/rfc2616/rfc2616.html. Generally, a client(i.e., the device requesting an object) maintains copies of resources ina local cache so that the resources can be used to satisfy futurerequests without the need to retrieve the objects from the origin server(i.e., the server that provides the object). Intermediate servers (i.e.,servers in the HTTP response-request chain in-between the client andorigin server) also may maintain copies of resources in an associatedcache. The cached resources may be, for example, a web page (e.g., ahypertext mark-up language (HTML) document or “top page”) or theresources embedded in a web page (e.g., images, style sheets, orJavascript files). As part of the HTTP protocol, an origin server canset a time (generally referred to as the expiration time) until which acacheable object remains valid, i.e., until which the object will remainunchanged and, therefore, until which the cached object can be used.When the expiration time has been reached, the cache may attempt tosimply validate the cached object (e.g., by verifying with the originserver that the cached object is unchanged) to enable further use of thecached resource. The HTTP protocol has additional mechanisms that causea client to validate a cached resource before using it. For example, anHTTP server can force a cache to validate cached resources after theybecome stale by using the “must-revalidate” cache-control directive ofthe HTTP protocol (see section 14.9 of the HTTP 1.1 protocol).

SUMMARY

In one general aspect, to validate embedded resources in a web page, avalidation message is sent by a client system executing a web browser.The validation message identifies at least one resource embedded in aweb page and is sent prior to the web browser issuing a validationrequest for the embedded resource. The validation message is receivedfrom a client system, for example, by a traffic server (e.g., a cachingweb proxy). The traffic server generates a request to validate theembedded resource identified in the validation message and sends therequest to validate the embedded resource to a server. In response tothe request sent to the server, a validation response is received, forinstance, by the traffic server. The traffic server sends the validationresponse to the client system to provide the validation response to theweb browser rendering the web page to satisfy a request issued by thebrowser to validate the embedded resource.

Implementations may include one or more of the following features. Forexample, the request to validate the embedded resource may include aconditional-GET. The validation message may be received in a singlemessage.

Multiple validation messages may be received from one or more clientsystems by, for example, the traffic server. The traffic server maygenerate an aggregate page structure by determining common embeddedresources among the multiple validation messages and may prioritize therequest to validate the embedded resource based on the validationmessage sent by the client system and the aggregate page structure.

Alternatively, or additionally, the traffic server may generate ordesignate an aggregate page structure by determining which one of themultiple validation messages was most recently received. A determinationto send the request to validate the embedded resource may be made basedon a union of the aggregate page structure and the validation messagesent by the client system.

In another general aspect, to validate embedded resources in a web page,a page structure may be generated, for example, by a client system. Thepage structure corresponds to a web page and indicates at least oneresource embedded in the web page. The client system generates avalidation message based on the page structure. The validation messageidentifies the embedded resource and is sent to a first server prior toa web browser issuing a request to validate the embedded resource. Avalidation response for the embedded resource is received by the clientsystem from the first server. The validation response is provided to aweb browser rendering the web page to satisfy a request to validate theembedded resource issued by the web browser.

Implementations may include one or more of the following features. Forexample, requests for embedded resources in the web page may be sent bythe client system during an initial rendering of the web page. The pagestructure may be generated based on responses received in response tothe requests for embedded resources sent during the initial rendering ofthe web page.

The page structure may be updated based on responses received inresponse to requests for embedded resources sent during a subsequentrendering of the web page. Alternatively, or additionally, the pagestructure may be updated based on a sibling web page. For instance, thepage structure corresponding to the web page may be updated based onresponses received in response to requests for embedded resources sentduring a rendering of the sibling web page. The sibling web page may bedetermined by determining whether a URL for the web page is similar to aURL for a second web page based on canonicalizing the URL for the webpage and the URL for the second web page. When the URL for the web pageis determined to be similar to the URL for the second web page, adifferential mapping may be performed between the page structurecorresponding to the web page and a page structure corresponding to thesecond web page to determine if similarities between the page structuresexceed a threshold.

The first server may include a traffic server (which, e.g., may be acustomized HTTP proxy server) on a ISP network. The validation messagemay be sent to the first server substantially simultaneous to receivinga request for the web page from the web browser. A single validationmessage may be generated. The validation message may identify theembedded resource by indicating a URL for the embedded resource. Thepage structure may only indicate cacheable embedded resources of the webpage. Cached copy of embedded resources identified in the validationmessage may already be stale when the validation message is generated,or will become stale at a set time in the future when the validationmessage is generated.

The first server may send a request to validate the embedded resourceidentified in the validation message to a second server and thevalidation response received from the first server may include avalidation response received by the first server from the second server.

Implementations of the described techniques may include hardware, amethod or process, or computer software on a computer-accessible medium.

The details of one or more implementations are set forth in theaccompanying drawings and the description below. Other features will beapparent from the description and drawings, and from the claims.

DESCRIPTION OF DRAWINGS

FIG. 1 is a diagram showing a networked system that supports the HTTPprotocol with local caching and validation.

FIG. 2A is an illustration showing a web browser interface configured todisplay a web page.

FIG. 2B shows a portion of web page code that corresponds to the webpage shown in FIG. 2A.

FIG. 3A is an illustration showing an example of an HTTP request.

FIG. 3B is an illustration showing a portion of an HTTP response to theHTTP request shown in FIG. 3A.

FIG. 4A show a diagram illustrating a process that may be implemented inthe system of FIG. 1 to assist in reducing latencies in rendering a webpage.

FIG. 4B shows an example of a portion of a page structure for a webpage.

FIGS. 5-7 show diagrams that illustrate processes that may be used toimplement actions in the process shown in FIG. 4A.

DETAILED DESCRIPTION

Latencies in rendering a web page and embedded resources may be reducedby beginning the process of validating cached resources embedded in theweb page prior to the time the browser issues a request to validate theembedded resources. A web browser may execute on a client system andrequest and render a web page. Resources embedded in the web page may bestored in a browser cache for use during subsequent renderings of theweb page. Some of the cached resources, however, may become stale priorto a subsequent rendering of the web page. Consequently, during asubsequent rendering, the browser may issue validation requests for thestale cached resources.

To reduce latencies in rendering a web page, a page structure may beused to begin validation of an embedded resource prior to the time thebrowser issues a request to validate the embedded resource. A pagestructure includes information indicating one or more embedded resourcein the web page and, in some implementations, its corresponding cachecharacteristics. For example, the page structure may include the URLscorresponding to cacheable resources embedded in the web page and theircorresponding cache characteristics. A page structure may be generated,for example, when the web page is first requested and rendered.

The next time the browser renders the same web page, the page structuremay be used to generate a validation message that indicates resources tobe validated. For example, when the page structure includes cacheable,embedded resources and their cache characteristics, the page structuremay be used to generate a single validation message that indicates thecacheable resources that currently need to be validated. The indicationsof the resources in the validation message may be compressed orotherwise represented in a compact form.

The validation message may be sent to a server prior to the web browserissuing a validation request for the embedded resource (e.g., atsubstantially the same time that the browser makes the request for theweb page or begins rendering the web page). The server can then beginvalidating the resources indicated in the validation message by sendingvalidation requests to an origin or other server storing the embeddedresources. The server then may send the validation responses back to theclient computer executing the browser so that the validation responsescan be used to satisfy corresponding validation requests generated bythe browser.

By sending a validation message around the time that the browser makesthe request for the web page or begins rendering the web page(particularly when a single validation message is used), the process forvalidating a resource in the browser cache is started before the instantat which the browser issues a request to validate the resource, leadingto increased page rendering speed. Furthermore, sending a singlevalidation message reduces the number of TCP connections needed betweenthe client and ISP network for validation and, also, thereby reduces thenumber of HTTP requests sent to ISP network. Such a reduction in thenumber of TCP connections to process validation requests eliminates thelatency associated with the TCP connections not made and results in acorresponding reduction in the number of bytes associated with thereduced number of required HTTP headers, and thus also may contribute toan increase in page rendering speed. Similarly, compressing theresources indicated in the validation message may result in a reductionof the number of bytes sent to ISP network, which may contribute toincreasing the page rendering speed.

Referring to FIG. 1, a networked system 100 supports the HTTP protocolwith local caching and validation. System 100 includes a client computer102 connected to, e.g., an ISP network 104. ISP network 104 is connectedto the Internet 110, which is connected to an origin server 112.

Client computer 102 executes a hypertext transfer protocol (HTTP) webbrowser 103. A web browser is generally a client software program thatis capable of rendering various kinds of resources available on anetwork such as the Internet. Web browser 103 includes a local browsercache 103 a for caching resources (such as web pages and resourcesembedded in web pages) received, e.g., from origin server 112.

Client computer 102 also executes an accelerator 105, which includes alocal accelerator cache 105 a for caching resources such as web pagesand resources embedded in web pages, along with other items (such aspage structures). Accelerator 105 also assists in reducing latencies inrendering resources (such as web pages) that include cacheable, embeddedresources.

ISP network 104 includes a load-balancing proxy server 106 connected toone or more traffic proxy servers 108 (which, e.g., are custom HTTPproxy servers that process the previously described validationmessages). Traffic proxy servers 108 also include a traffic server cache108 a for caching resources and may cooperate with accelerator 105 toassist in reducing latencies in rendering resources that includecacheable, embedded objects or other resources (as described furtherbelow).

Origin server 112 may execute HTTP server software to respond to datarequests from the HTTP-based web browser 103. The HTTP data requestsfrom browser 103 can target various types of resources on server 112,such as documents (e.g., web pages) or so objects (e.g., images, stylesheets, Javascript files, executable files, audio files, or videofiles).

In general, browser 103 may be used to navigate to a particular webpage, for example, through the entry of a Uniform Resource Locator (URL)into a navigation bar of web browser 103 or selection of a hyperlink inanother web page. When the web page is not cached in browser cache 103a, accelerator cache 105 a, or traffic server cache 108 a, the requestis forwarded from web browser 103 to origin server 112 throughaccelerator 105, proxy 106, and one of traffic servers 108. Originserver 112 then may return the requested web page to browser 103 throughthe traffic server 108, proxy server 106, and accelerator 105. Webbrowser 103 renders the received web page. For subsequent requests forthe web page by browser 103, accelerator 105 and traffic server 108 mayoperate to reduce latencies in the rendering of the web page, asdescribed further below.

Referring to FIG. 2A, web browser 103, e.g., receives and renders webpage 210. The term web page as used herein refers generally to documentsand other resources capable of being read and rendered by a browser.

Web page 210 is composed of text, hyperlinks and a number of embeddedobjects or other resources, such as embedded graphics. For example, webpage 210 includes graphics 212-218, hyperlinks 226, and text 228. Whilenot shown, the embedded objects or other resources also can include,e.g., audio files, video files, executable files, other web pages, stylesheets, Javascript files, or other resources.

Web pages are typically text files written in a standard or proprietarylanguage that is understood by browser 103. Some standard languagesinclude HTML and the extended mark-up language (XML). The text file(otherwise referred to as web page code) constitutes instructions to theweb browser 103 as to what browser 102 should do to render the web pageand embedded resources in the web page. Web browser 103 processes theweb page code (e.g., a HTML text document), fetches the embeddedresources, and renders the web page and embedded resources to the useraccordingly. While the term rendering normally connotes converting froma file into a visual form, when a browser renders some embeddedresources, their rendering may result in non-visual components of theweb page. For example, Javascript may result in non-visual components ofthe web page. Accordingly, the term rendering should be understood tomore broadly include the browser's processing of a so resource, whetherthe processing results in visible components or non-visible components.

The text and hyperlinks for a web page typically are included in the webpage code. By contrast, graphics and other embedded resources typicallyneed to be retrieved when browser 103 renders a web page. The web pagecode includes instructions that direct browser 103 to the location ofthe embedded resources to be loaded (typically located on the serverthat provided the web page code). As browser 103 encounters theinstructions in the web page code, browser 103 uses the instructions toretrieve the embedded resources and render the resources in the webpage. The web page code and retrieved resources may be cached in browsercache 103 a or accelerator cache 105 a for use in subsequent renderingsof the web page by browser 103. The web page code and retrievedresources also may be cached in traffic server cache 108 a for use insubsequent renderings of the web page by browser 103 or other browsers.

FIG. 2B shows a portion 230 of web page code that corresponds to webpage 210. The web page code for rendering web page 210 is written inHTML. HTML consists of text “tags” that provide browser 103 with certaininformation and instruct the browser 103 how to display thatinformation. A tag is text surrounded by the brackets “< >.” In theexample provided by portion 230, tags 232-236 primarily instruct browser103 as to where browser 103 is to display graphic 212. Tags 238 a and238 b instruct browser 103 to display graphic 212 and to hyperlinkgraphic 212 to a particular web page (in this case, graphic 212 ishyperlinked to web page 210). The anchor tag 238 a, <a>, instructsbrowser 103 to create the hyperlink. The image tag 238 b, <img>,instructs browser 103 to insert graphic 212. Image tag 238 b includesthe location of graphic 212 as an argument. The location of the graphic212 is expressed as a URL 240.

URL 240 is an embedded URL and corresponds to an embedded object in webpage 210, namely, graphic 212. Other URLs also may be embedded in theweb page code and may correspond to objects or other resources (visibleor non-visible) embedded in web page 210.

URL 240 includes several sections that identify the location of graphic212. A first section 242 indicates that graphic 212 is located at asever whose domain name is “i.a.cnn.net.” First section 242 alsoindicates that graphic 212 is available at the server via the HTTPprotocol. A second section 244 indicates the directory location ofgraphic 212 on the server. A third section 246 indicates the filename ofgraphic 212, namely, “logo.gif.”

Using the URL 240 and the domain name system (DNS), graphic 212 can beretrieved from the origin server (e.g., origin server 112) and rendered.For example, web browser 200 can send a request (e.g., an HTTP request)to traffic server 108. The request includes URL 240 and traffic server108 uses the DNS to determine the address of origin server 112 andlocation of graphic 212 on the origin server 112. Traffic server 108then sends a request (e.g., HTTP request) to origin server 131 forgraphic 212. Origin server 112 sends a response that includes graphic212 to traffic server 108, which forwards graphic 212 to browser 103such that browser 103 can then render graphic 212 in web page 210.

Referring to FIG. 3A, an example of an HTTP request 300 for graphic 212includes a structured sequence of fields 302-306. Each field 302-306includes an HTTP header and data associated with the header. Forexample, field 302, which may be referred to as the start line, includesthe phrase “GET,” which indicates that the HTTP request uses the “GET”method and also includes the filename and location of graphic 212 on theorigin server, namely, “/cnn/.element/img/1.1/logo/logo.gif.” In field304, header “Host:” indicates the origin server from which graphic 212is to be obtained. In request 300, the server is the server whose domainis “i.a.cnn.net.” Field 306 includes the HTTP header “User-Agent:.” Thedata of field 306 is “Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0;Q312461),” which designates the type of browser generating the request300.

Referring to FIG. 3B, an HTTP response 350 to request 300 may include astructured sequence of fields 352-362 and graphic 212 (not shown in FIG.3B). Field 352 includes an indication of the version of the HTTPprotocol (“HTTP/1.1”) and a status code (“200 OK”) that reflects theresult of the origin server's or an intermediate server's attempt tosatisfy request 300. A status code of “200 OK” indicates the attempt wassuccessful. Field 354 indicates the date and time response 350 wasgenerated. Field 356 indicates the media-type of the data or object (inthis case, graphic 212) returned by response 350. In the case of graphic212, the media-type is “image/gif,” which indicates that the object isan image in the “gif” format. Field 358 indicates the date and time thatgraphic 212 was last modified or changed. Field 362 indicates the lengthof the data or object (graphic 212) returned by response 350.

Field 360 indicates cache characteristics of the object (graphic 212)returned by response 350. Field 360 includes cache directives from theserver that provided response 350. The cache directives indicate howcaches in the request-response chain (e.g., browser cache 103 a,accelerator cache 105 a, and traffic server cache 108 a) are suppose tohandle caching of graphic 212 and subsequent requests for the graphic212. The “max-age” directive indicates the time in seconds from the timethe response containing the object is generated until the cached versionof graphic 212 becomes stale. The “must-revalidate” directive forces acache (assuming the cache follows the HTTP 1.1 specification) toimmediately mark graphic 212 as stale.

Referring to FIG. 4A, a process 400 may be implemented in system 100 toassist in reducing latencies in rendering a web page stored, forexample, on origin server 112. When web browser 103 is used to navigateto a web page stored on origin server 112 and browser cache 103 a isclear of the corresponding web page code (402), a request directed toorigin server 112 is sent from web browser 103 to accelerator 105 (404).

When accelerator 105 receives the request for the web page, accelerator105 retrieves the corresponding web page code and provides the web pagecode to browser 103 (406). Accelerator 105 may retrieve thecorresponding web page code from accelerator cache 105 a when there is afresh or validated copy in accelerator cache 105 a, or from originserver 112 or other cache (e.g., maintained at traffic server 108) inthe absence of a fresh or validated copy in accelerator cache 105 a.

Referring to FIG. 5, more specifically, when accelerator 105 receivesthe request, it first checks to see if a cached copy of the web page isavailable in accelerator cache 105 a (502).

If a cached copy is available (502), a determination is made whether thecopy is stale (504). When not stale (504), accelerator 105 provides aresponse to browser 103 that includes the cached copy to satisfy thebrowser's request (516). On the other hand, when the web page code inaccelerator cache 105 a is stale (504), accelerator 105 validates theweb page code (506). For instance, to validate the web page code (506),accelerator 105 may send a conditional-GET request for the web page codeto origin server 112 or other server on which the web page code islocated and the conditional-GET request may follow the same path toorigin or other sever 112 as a standard GET request for the web page orother resource. In the HTTP protocol, a conditional-GET has anIf-Modified-Since header that includes, e.g., the expiration time of theresource or the time in a Last-Modified header included in the responsethat originally provided the resource. If the resource has not beenmodified since the time specified in the If-Modified-Since header, theresource will not be sent back. Instead a 304 (Not-Modified) responsewith only the relevant resource meta-information headers (e.g., a newexpiration time) will be returned. If the resource has been modified, a200 (OK) response that includes the modified resource will be sent back.If the resource no longer exists, a 404 (File-Not-Found) response isreturned. In the absence of a File-Not-Found response, accelerator 105provides a response to browser 103 that either includes thenewly-received web page code (if an OK response is returned) or thecached copy originally stored in accelerator cache 105 a (if aNot-Modified response is returned) (516).

While the foregoing describes techniques that use the last-modified orexpiration times for validating an object, other validators may be used.For instance, entity tags (etags) may be used for validation as analternative, or in addition to, last-modified times or expiration times.

If no cached copy of the web page code is available in accelerator cache105 a (502), accelerator 105 forwards the request to ISP network 104(508) to retrieve the web page code from origin server 112 (or a cachedcopy of the web page from traffic server 108). The request is routed toproxy server 106 (510), which load balances requests among one or moretraffic servers 108 by selecting a traffic server 108, as appropriate,to balance the load on traffic servers 108, and forwarding the requestreceived from client computer 102 to the selected traffic server 108(512).

After receiving the forwarded request, the selected traffic server 108checks to determine if a traffic server cache 108 a contains a copy ofthe web page code. If traffic server cache 108 a contains a copy of theweb page code and the copy is fresh, traffic server 108 retrieves theweb page code from traffic server cache 108 a and provides a response tobrowser 103 that includes the web page code. If traffic server cache 108a contains a copy of the web page code, but the copy is stale, trafficserver 108 may validate the web page code and provide a response tobrowser 103 that contains a validated copy of the web page code.

If traffic server cache 108 does not contain a copy of the web pagecode, traffic server 108 forwards the request to origin server 112 toretrieve the web page code from origin server 112. When traffic server108 receives the web page code from origin server 112, traffic server108 forwards the web page code to accelerator 105 through proxy server106 (514). Accelerator 105 then provides a response to browser 103 thatincludes the web page code received from traffic server 108 (516).

Referring again to FIG. 4A, when browser 103 receives the web page codefrom accelerator 105 (406), browser 103 begins rendering the web page(408), sending requests for the embedded resources in the web pageand/or requests for validation of resources embedded in the web page toaccelerator 105.

All the while, and upon receipt of a browser request for the web page orvalidation of one or more resources embedded therein (404), accelerator105 determines whether a page structure associated with the web page isstored in accelerator cache 105 a (410). For example, the requested webpage's URL may be used as an index to perform a cache lookup for anassociated page structure stored in accelerator cache 105 a. Whileoperations 406 and 410 are shown such that they are performedasynchronously, these operations may be performed in a more sequentialmanner. For instance, accelerator 105 may first check for a cachedversion of the requested web page in accelerator cache 105 a beforeperforming operation 410. Providing a cached version of the requestedweb page to browser 103 may significantly reduce latency, and therefore,the check for a cached version in accelerator cache 105 a (406) may begiven priority over operation 410 to insure that the benefits fromproviding the cache copy are achieved.

Referring to FIG. 4B, a page structure 450 identifies one or moreembedded resources within a web page and cache characteristicsassociated with the embedded resources, such as the expiration time(which indicates when the resource is presumed to become stale) or othervalidators (e.g., last-modified time or etag), or an indication that theresource must always be validated. In one implementation, the pagestructure includes only a subset of the resources embedded within a webpage, such as the embedded resources that are cacheable, along withtheir corresponding cache characteristics.

A page structure also may include other information pertinent to arequest for a resource (not shown in FIG. 4B), such as personalizationinformation. For example, some URLs point to a resource, but theparticular resource returned depends on other information included inthe request for the resource, such as information added to the requestfrom a cookie. For instance, there may be web page code that is in onelanguage and web page code that is in another language. Which web pagecode is returned in response to a request for the web page may depend ondemographic information added to the request from a cookie. Thus, forexample, if the added information indicates the browser is located in anEnglish speaking country, an English version of the web page may bereturned, while a browser in a French speaking country may receive aFrench version of the web page. The alternate language selection may becontrolled by data in an “Accept-Language” header.

A page structure may be organized by associating the URLs of theembedded resources with the URL of the web page. Accordingly, a pagestructure may include URLs corresponding to cacheable resources embeddedin the web page, with the URLs associated with the cache characteristics(and possibly other information such as cookies) of those resources. Asdescribed further below, a page structure may be generated based on therequests made and corresponding responses received when a web page isrendered.

FIG. 4B shows an example of a portion of a page structure 450 for webpage 210. As shown, page structure 450 includes the embedded URL 402corresponding to graphic 212, and the corresponding cachecharacteristics 404 as indicated in a HTTP response containing graphic212 or a validation response to validate graphic 212.

Referring again to FIG. 4A, if accelerator 105 finds in acceleratorcache 105 a a page structure associated with the requested web page(410), accelerator 105 uses the page structure to identify resourcesembedded within a requested web page that will presently requirevalidation by a rendering browser, and thus, to generate validationmessage(s) corresponding to those identified resources), which are sentto traffic servers 108 (412).

As such, accelerator 105 may identify requests for validation that willbe issued by a browser seeking to render the web page before the browserencounters those resources in the web page code, thus enabling advancedprocessing of those validation requests. Generally, the validationmessage indicates embedded resources of the web page (e.g., indicatesthe URLs of embedded resources) and is sent to traffic server 108 priorto browser 103 issuing validation requests for the embedded resources(e.g. the validation message is sent with a request for the web page oraround the time browser 103 begins rendering the web page). Trafficservers 108 use the validation message to validate at least a portion ofthe indicated resources, and return the validation results toaccelerator 105 (412).

Referring to FIG. 6, an exemplary process is described in greater detailto illustrate how accelerator 105 can send a validation message andreceive responses thereto. Specifically, accelerator 105 uses the pagestructure to generate a validation message that includes all of theresources identified in the page structure or a subset of thoseresources (602). For instance, accelerator 105 may inspect the cachecharacteristics in the page structure to identify only those resourcesthat currently require validation (i.e., those resources that havealready grown stale) and generate a validation message based on acorresponding set of embedded resources, or it may be a less restrictiveselection process, such as a process to generate a validation messagethat includes all of the embedded resources eligible for validation,including the resources that currently need validation and thoseresources that will need validation at some set time in the future, oraccelerator 105 may simply forego a selection process altogether andsimply submit all embedded resources in a validation message. In oneexample, the validation message may indicate the resources thatcurrently need validation plus the resources that will expire within 30minutes. Including resources that will expire at some time in the futuremay extend the life of those resources in accelerator cache 105 a as aresult of traffic servers 108 returning a new expiration time for theresource in the validation results. For instance, if a new expirationtime is returned to accelerator 105 in response to a validation requestfor a resource (whether presently identified as stale or not),accelerator cache 105 a may update the expiration time of the resourcein accelerator cache 105 a. Consequently, in a subsequent rendering ofthe web page, even if a cached resource were previously deemed bybrowser cache 103 a to be stale (and possibly removed from browser cache103 a), accelerator cache 105 a may nevertheless maintain a valid cachedcopy of the resource (because of the updated expiration time). As aresult, when browser 103 issues a request for the resource (because theresource has been flushed from browser cache 103 a) or issues avalidation request for the resource (because the resource has beenmarked as stale in browser cache 103 a), accelerator 105 may be able torespond appropriately with the resource or a validation response withoutthe need to retrieve the resource from origin server 112 or other serverand/or without the need to validate the copy of the resource inaccelerator cache 105 a. Moreover, accelerator 105 may identify updatedexpiration times, when determined, to browser 103 to enable more usefulbrowser caching of resources whose expiration schedule changes.

As another alternative, accelerator 105 may generate a validationmessage that indicates all of the embedded resources in the web page,with or without the associated cache characteristics, and allows thetraffic servers 108 to select which resources to validate (as describedfurther with respect to action 608). When the validation messageindicates all of the embedded resources and does not include cachecharacteristics, the page structure may not include the cachecharacteristics.

Validation messages may vary in substance or form. Substantively, forexample, validation requests may vary with respect to the type andamount of information, such as personalization information, that isprovided for the embedded resources for which validation is beingrequested. For instance, if the resource that is returned depends oninformation added to a request from a cookie, the information in thecookie (which may have been stored in the page structure, as describedabove) may be sent or referenced in the validation message also. Inaddition, with respect to substance, the validation message may indicatethe resources by indicating the corresponding URLs for the resources, ormay include some other identifier of the resources.

With respect to variations in form, validation messages may be submittedseparately for each of several resources embedded within a web page, orthey may be submitted in a single message. More specifically,accelerator 105 may generate a single validation message that indicatesthe embedded resources, and the single validation message may indicatethe resources in a compressed or compact form so as to reduce the numberof bytes needed for the message. By contrast, in some implementations,more than one validation message may be generated.

Accelerator 105 sends the validation message to proxy server 106 (604).Proxy server 106 may break down the received the validation message intoone or more groups of resources indicated by the validation message(e.g., proxy server 106 may break down the validation message into oneor more groups of URLs for the indicated resources) and distribute thevalidation load amongst one or more traffic servers 108 (606). Bycontrast, in an alternate implementation, proxy server 106 may forwardthe entire validation message to a traffic server 108 and let thetraffic server 108 break down the validation message (606). In such acase, traffic server 108 may forward individual indications of theresources (e.g., the URL of the resources) to other traffic servers 108to further balance or more appropriately allocate the load. At 608, theappropriate traffic server(s) 108 then validates at least a portion ofthe resources indicated by the validation message by sending requests tothe origin server 112, or other server (608). Some resources may bestored in traffic server cache 108 a and valid. In such a situation,traffic server 108 may generate and return a validation response withoutsending a validation request to origin server 112 first.

To validate resources (608), traffic server 108 may send conditional-GETrequests for the embedded resources to origin server 112 or other serveron which the embedded resources are located. Traffic server 108 mayobtain the time used in the If-Modified-Since header from previousresponses received by traffic server, or the time may be included in thevalidation message. If validation is based on etags (e.g., usingIf-None-Match header), then traffic server may send an etag received inthe validation message to origin server 112.

The particular resources selected from the validation message forvalidation by traffic server 108 may depend on the information and/orwhich resources are identified by the validation message. As describedabove, the validation message may include (1) only those resources thatcurrently require validation, (2) those resources that currently requirevalidation plus those resources that will require validation at a timein the future, or (3) all of the cacheable resources embedded in a webpage, with or without their associated cache characteristics.

Several example scenarios are described to illustrate the various waystraffic server 108 may select resources identified in the validationrequest for validation, depending, in part, on the information providedin the validation message received by a traffic server 108 fromaccelerator 105. In one example, where the validation message indicatesonly those resources that currently require validation, or those thatcurrently require validation plus those resources that will needvalidation at a time in the future, traffic servers 108 may validate allof the resources included in the validation request.

In another example, where the validation message indicates all ofembedded resources and includes the associated cache characteristics,traffic servers 108 may select and validate the resources that haveexpired and/or those that will expire at some time in the future. In yetanother example, where the validation message indicates all of theembedded resources but not the associated cache characteristics, trafficservers 108 may validate all of the indicated resources. In stillanother example, where the validation message indicates embeddedresources without cache characteristics, traffic servers 108 may selectand validate the resources that have expired and/or resources that willexpire at some set time in the future if traffic servers 108 otherwisehave the cache characteristics available (e.g., as a result of requestsfrom other clients).

In some implementations, one or more traffic servers 108 may validateembedded resources through an inspection of additional informationstored at traffic servers 108, before or as an alternative to sendingrequests to origin server 112, For instance, traffic servers 108 maystore aggregate page structures or authoritative page structures for webpages and, during action 608, these server-based page structures may beused to optimize resource validation.

More specifically, traffic servers 108 generally process validationmessages from multiple client computers and, therefore, have access tomultiple validation messages for a given web page. Traffic servers 108may use these multiple validation messages sent by various clientmachines to generate page structures and the type of page structuregenerated may depend on the particular web page requested.

Dynamic aggregate page structures may be generated for web pages havingcontent that is dynamic or personal content or otherwise frequentlychanging. If the web page contains dynamic content (e.g., if the webpage is personalized to the user or generated by a applet or a program),the embedded resources indicated in validation messages from differentclients may be different for the same web page (or may be different evenif they are from the same client if there is more than one user of theclient). Similarly, because the validation messages are occurring atdifferent times, the validation messages may be different because theweb page has changed. As a result, over a number of validation messagesreceived for a web page (e.g., a few thousand), traffic server 108 maydetermine the associated URLs that are common to the differentvalidation messages and build a dynamic aggregate page structure basedon the common URLs.

By contrast, static aggregate page structures may be generated for thosepages whose content is not dynamic, personalized or otherwise frequentlychanging over time. As described, in general, traffic servers 108process validation messages from multiple client computers and,therefore, have access to multiple page structure data. An authoritativepage structure for a web page is based on the validation message thathas the most recent timestamp from within a configured time frame (e.g.all the validation messages for a web page that traffic servers 108receive in the last one hour are examined and the validation messagewith the latest time stamp is designated as the authoritative pagestructure—1 hour in this example is the configured time frame).

Both dynamic and static aggregate page structures may be used tooptimize the validation requests sent by traffic server 108 to originsever 112 (or other server). When the page is one that is personalizedbased, e.g., on information stored in a cookie or an output of a program(e.g., a dynamic page generated by a common gateway interface (CGI)program or Java Servlet), the dynamic aggregate page structure may beused to prioritize the resource validations indicated in the validationmessage. For instance, validation requests for resources in both thevalidation message and the dynamic aggregate page structure may be sentbefore the validation requests for resources that are not in both thevalidation message and the dynamic aggregate page structure. Conversely,when the page is not one that is personalized, then the union of thestatic aggregate page structure and the resources indicated in thevalidation message may be used to determine which resources to validate.For instance, if the client computer 102 sends a validation message withURL A to traffic server 108 to be validated, but the static aggregatepage structure indicates that URL A does not exist, then traffic server108 may not validate URL A. Alternatively, traffic server 108 may orderthe validations such that URL A is validated after the other resources.

At least a portion of the validation results are sent to accelerator 105when they are received by traffic server 108 (610). As describedpreviously, traffic servers may send a conditional-GET to validate theresources. In this case, traffic servers 108 generally receive one ofthree responses for each resource being validated: a Not-Modifiedresponse, an OK response including the modified resource, or aFile-Not-Found response. These responses may be streamed back toaccelerator 105 as they are received by traffic server 108.

Referring again to FIG. 4A, accelerator 105 provides responses tobrowser 103 to satisfy the validation requests and requests for embeddedresources issued by browser 103 as browser 103 renders the web page(414). Generally, browser 103 issues (1) requests for embedded resourceswhen browser cache 103 a does not contain cached copies of thoseresources, and (2) validation requests when cached copies of thecorresponding resources in browser cache 103 a have expired and includea must-revalidate directive, or otherwise require validation (e.g., haveexpired without a must-revalidate directive).

With respect to requests for embedded resources, accelerator 105satisfies these by providing a response that includes the resource fromaccelerator cache 105 a when a valid copy of the resource is located inaccelerator cache 105 a (414), or by providing an appropriate responsebased on the validation results from traffic servers 108 when the cachedcopy in accelerator cache 105 a is stale (414). Otherwise, if a cachedcopy of the resource is not stored in accelerator cache 105, accelerator105 forwards the request to ISP network to retrieve the resource fromorigin server 112 or other server and provides the response to theforwarded request to browser 103 (414).

With respect to validation requests, accelerator 105 satisfies these byproviding the appropriate response to the request based on thevalidation results received from traffic servers 108 (414).

FIG. 7 illustrates one exemplary process that may be used to satisfyrequests for embedded resources and validation requests received byaccelerator 105 (414), which takes advantage of information obtainedthrough the processes of actions 410 and 412 to decrease the latency inthe rendering of the web page. The latency may be reduced in twosituations. First, the latency may be reduced when accelerator processesrequests for embedded resources received from browser 103 (714). Second,the latency may be reduced when accelerator 105 processes validationrequests received from browser 103 (716).

With respect to requests for embedded resources, there are two scenariosin which the latency may be reduced. As described above, the validationmessage sent to ISP network 104 by accelerator 105 in action 412 mayidentify resources embedded in the web page that have not expired yet.As a result, these resources may still be stored in accelerator cache105, even though they have expired and, possibly, been deleted from thebrowser cache. In fact, some of these resources may still be fresh inaccelerator cache 105 a. As such, the first scenario includes a resourcethat has been cleared from the browser cache, but is still stored inaccelerator cache 105 a and has not expired in accelerator cache. Inthis case, the latency may be reduced because accelerator 105 is able toimmediately provide the resource to so browser 103 in response to thebrowser's request for the resource. In the second scenario, the resourcehas been cleared from browser cache 103 a, but is still stored inaccelerator cache 105 a and has expired in accelerator cache 105 a. Inthis case, the resource may have been identified in the validationmessage sent by accelerator 105 in action 412. Consequently, avalidation result may have been received by accelerator 105 before therequest for the embedded resource is sent to accelerator 105 by browser103. Accelerator 105, therefore, may be able to immediately provide theresource to browser 103 in response to the browser's request for theresource.

With respect to requests for validation, latencies may be reducedbecause the validation message sent by accelerator 105 in action 412 mayhave identified the resource for which validation is requested. As aresult, accelerator 105 may have received the validation result for theresource before the browser issues the validation request or shortlythereafter. Consequently, a response to the validation request can beprovided to browser 103 sooner than if the validation request sent bythe browser 103 was forwarded to ISP network 104 to perform thevalidation of the resource.

More specifically, with respect to the actions performed for requestsfor embedded resources, accelerator 105 receives a request for anembedded resource from browser 103 when the embedded resource is notstored in browser cache 103 a (702). When accelerator 105 receives therequest for the embedded resource (702), accelerator 105 determineswhether a cached copy of the resource is located in accelerator cache105 a (704).

If the resource is not stored in accelerator cache 105 a, accelerator105 forwards the request to ISP network 104 and receives a response tothe request from origin server 112 or other server (706). The responsemay be, for example, an OK response that includes the resource or may bea File-Not-Found response. When accelerator 105 receives the response,accelerator 105 satisfies the browser's request by providing theresponse to browser 103 (708).

For example, if the web page includes an image, the browser 103 sends arequest directed to, e.g., the origin server 112 or another server, toretrieve the image for display in the rendered web page. This requestfor the image is first routed to the accelerator 105, which, whenaccelerator cache 105 a does not contain a copy of the image, forwardsthe request to a traffic server 108 through proxy server 106. If theimage is cached at the traffic server 108, the traffic server 108 mayrespond to the request by sending the image. Otherwise, the trafficserver 108 forwards the request to the origin server 112 or anotherserver. The origin server 112 or other server then responds by sendingthe image. The response generated by origin server 112 or other serveris sent back to accelerator 105 through ISP network 104. Accelerator 105provides the response (which may include the requested resource) tobrowser 103 to satisfy the outstanding request generated by browser 103for the resource. In addition, if a resource is returned and iscacheable, accelerator 105 may store it in accelerator cache 105 a.

On the other hand, if a cached copy of the requested resource is locatedin accelerator cache 105 a (704), accelerator 105 determines whether thecached copy is stale (710). If the cached copy is not stale, accelerator105 provides a response to browser 103 that includes the cached copy ofthe resource. As described above, there may be resources that are storedin accelerator cache 105 a that are not stale and not stored in browsercache 103 as a result of validation requests sent during previousrenderings of the web page or the validation request sent during thecurrent rendering of the web page. This may result in accelerator 105being able to immediately respond to the browser's request for theembedded resource.

If, on the other hand, the cached copy of the resource is stale (710),then, as described above, an indication of the resource may have beenincluded in the validation message. In this case, accelerator 105 maywait for the validation result corresponding to the requested resource(712) and, when accelerator 105 receives the validation result,accelerator 105 provides an appropriate response to browser 103 (714).For example, if the validation result includes a OK response with amodified resource, accelerator 105 provides a response to browser 103that includes the modified resource. If the validation result includes aNot-Modified response, accelerator 105 provides browser 103 with aresponse that includes the cached copy of the resource. If thevalidation result includes a File-Not-Found response, this response isprovided to browser 103. Also as described above, the validation resultmay be received before browser 103 sends the request for the resource orshortly thereafter, thereby decreasing the time until a response can beprovided to browser 103.

With respect to the actions performed for validation requests,accelerator 105 receives a validation request for an embedded resourcefrom browser 103 when the embedded resource is stored in browser cache103 a, but is stale or includes a must-revalidate directive, orotherwise requires validation (716). In this case, an indication of theresource may have been included in the validation message. Accordingly,when accelerator 105 receives the validation request for the embeddedresource (716), accelerator 105 determines whether the correspondingvalidation result has been received from traffic servers (718). If so,accelerator 105 provides the appropriate response to browser 103 basedon the validation result. If not, accelerator 105 may wait for thevalidation result corresponding to the requested resource (712) and,when accelerator 105 receives the validation result, accelerator 105provides the appropriate response to browser 103 based on the validationresult (714).

For example, if the validation result includes a OK response with amodified resource, accelerator 105 provides a response to browser 103that includes the modified resource. If the validation result includes aNot-Modified response, accelerator 105 provides this response to browser103, and browser 103 uses the copy of the resource located in browsercache 103 a. If the validation result includes a File-Not-Foundresponse, this response is provided to browser 103.

In some implementations, accelerator 105 may not wait for validationresults (action 712) when a cached copy of the resource is inaccelerator cache 105 a and stale or when accelerator 105 receives avalidation request, but the validation result has not yet been received.Rather, accelerator 105 instead may generate and send a (likely new andredundant) validation request when a cached copy of the resource is inaccelerator cache 105 a and stale (710) or may forward the validationrequest received from browser 103 when the validation result for theresource has not been received (718). In either case, the validationrequest is sent/forwarded to ISP network 104. Proxy server 106 andtraffic servers 108 then process the request and perform the validation,sending the response (Not-Modified, OK with modified resource, orFile-Not-Found) back to accelerator 105. Having the accelerator send orforward a validation request instead of waiting for validation resultsmay help to insure that a response is received for a given request, forexample, in the event a resource was not indicated in the validationmessage, a problem prevented traffic servers 108 from performing thevalidation based on the validation message, or a problem prevented thevalidation results from getting back to accelerator 105.

Referring again to FIG. 4A, accelerator 105 may generate or tune thepage structure for the web page based on the requests for the embeddedresources received from browser 103, validation requests received frombrowser 103, responses to requests sent by browser 103 or accelerator105, and/or validation results.

When the request for the web page is the first request for that web pageissued by browser 103 (or when the page structure has been cleared fromaccelerator cache 105 a), accelerator 105 may use the requests issuedand responses received while rendering the web page to generate the pagestructure. For instance, when the page structure includes only cacheableresources and their cache characteristics, accelerator 105 may receivethe request for the web page from browser 103 and generate anunpopulated page structure that is stored in accelerator cache 105 andindexed according to the URL of the web page. As accelerator 105receives requests for the embedded resources, accelerator 105 notes theURL of the embedded resources and then forwards the requests.Accelerator 105 also may note additional information, such aspersonalization information, that is added to the request from, forexample, a cookie. When a response to a request is received andindicates the corresponding resource is cacheable, accelerator 105enters the URL for the resource and cache characteristics for theresource into the page structure. Accelerator also may include theadditional information in the entry for the resource.

Alternatively, or additionally, authoritative page structures may beused by accelerator 105 as the base page structure. An authoritativepage structure corresponds to resources and information that the authorof the web page guarantees will be included in the web page.Authoritative page structures may be provided by origin or otherservers. Thus, for example, an authoritative page structure maycorrespond to web page 210 and be sent to accelerator 105 by originserver 112. The authoritative page structure includes resources that areguaranteed to be included in web page 210 and is stored by accelerator105 as the base page structure for web page. This may provide a pagestructure for web page 210 even if web page 210 has not been previouslyrequested, and also allows the accelerator to generate validationmessages that include resources that are guaranteed to be in web page210.

When a page structure is stored in accelerator cache 105 a, accelerator105 may use the requests and responses issued and received, and thevalidation results, to tune the page structure to include the currentembedded resources and their cache characteristics. For example, if aFile-Not-Found response is returned in response to a request for aresource or in response to validation of the resource, the entry in thepage structure corresponding to the so resource may be removed.Similarly, while rendering the web page, if browser 103 issues requestsfor resources that were not included in the page structure and an OKresponse is returned including the resource, then an entry for theresource may be added in the page structure. Furthermore, for instance,if new cache characteristics for a resource are returned as part of thevalidation results or as part of a response to a request for theresource, the entry for the resource may be updated to reflect the newcache characteristics.

An alternative or additional manner of updating the page structureinvolves the examination of sibling pages to determine updates to theresources in the page structure and/or their cache characteristics.

A sibling page is a related web page that shares some of the sameresources as the original web page for which the page structure wasconstructed. Some web sites use similar content across their web pages,for example, to create the same look and feel across the web pages. As aresult, many of the web pages for the web site use the same embeddedresources (for example, style sheets, java script, images for logos,etc.). For example, a web site (such as www.cnn.com) may use the samebanner image across the top of its web pages to indicate the name of theweb site. To discover sibling pages, the URLs of the web pages requestedby client computer 102 can be canonicalized to determine similar URLs,and a differential mapping can be performed on the page structures forthe similar URLs to determine similarities between the web pages. If thesimilarities exceed a particular threshold (which may be empiricallydetermined), then the pages are considered to be sibling pages. When thepage structures of a sibling page is changed, then entries for thecommon resources in the other sibling pages are changed as well. Forinstance, the cache characteristics of URLs common to a set of siblingpages may be updated with new characteristics when the URL in one of thesibling page's page structure is changed (e.g., as a result ofrequesting the web page associated with the URL). As another example, ifa common URL is deleted in the page structure of one sibling web page,it may be deleted in the other sibling pages.

The techniques described above are not limited to any particularhardware or software configuration. Rather, they may be implementedusing hardware, software, or a combination of both. The methods andprocesses described may be implemented as computer programs that areexecuted on programmable computers comprising at least one processor andat least one data storage system. The programs may be implemented in ahigh-level programming language and may also be implemented in assemblyor other lower level languages, if desired.

Any such program will typically be stored on a computer-usable storagemedium or device (e.g., CD-Rom, RAM, or magnetic disk). When read intothe processor of the computer and executed, the instructions of theprogram cause the programmable computer to carry out the variousoperations described above.

A number of implementations have been described. Nevertheless, it willbe understood that various modifications may be made. For example, whileproxy server 106 and traffic servers 108 have been illustrated, otherarchitectures may be used. For instance, a single traffic server 108 maybe used and/or proxy server 106 may be eliminated (i.e., a proxy serverto balance the loads may not be used or may be replaced with other loadbalancing technologies). Further, the functionality of traffic servers108 may be incorporated into accelerator 105 such that accelerator 105sends the requests for validation. Also, while a separate acceleratorcomponent 105 has been described, the functionality of accelerator 105may be incorporated directly into browser 103.

In addition, while the foregoing has described the various components ofnetwork 100 as using the HTTP protocol, other standard or proprietarycommunication protocols may alternatively be used. In anotherimplementation, for example, proprietary browsing software may executeon client computer 102 and may communicate with other computers on ISPnetwork 104 using proprietary protocols, or a mix of standard andproprietary protocols. Proxy server 106 or traffic servers 108 mayinterface service provider network with Internet 110 by translatingrequests and responses from the proprietary protocol into the standardprotocols. Additionally, if the browser executing on client computer 102only renders web pages written in a proprietary language and a web pagewritten in a standard language is retrieved from origin server 112,proxy server 106 or traffic servers 108 may convert the standardlanguage web page into a proprietary language web page.

In other implementations, Internet 110 may use other standard orproprietary communication protocols and web pages may be written inother standard or proprietary languages. In general, the standard orproprietary protocol or language used on Internet 110 may be the same ordifferent than the standard or proprietary protocol or language used onISP network 104.

Furthermore, techniques other than a conditional GET may be used tovalidate resources in an HTTP or other implementation.

Accordingly, other implementations are within the scope of the followingclaims.

1-26. (canceled)
 27. A method for validating cached embedded resourcesin a web page, the method comprising the following operations performedby at least one processor: receiving a validation message from a clientsystem executing a web browser, the validation message identifying atleast one resource embedded in a web page and stored in a cache of theweb browser, the validation message being sent by the client systemprior to the web browser issuing an HTTP validation request for theembedded resource; sending, to a server, a request to validate theembedded resource to determine whether the embedded resource has beenmodified since the embedded resource was stored in the cache of the webbrowser; receiving, in response to the request sent to the server, avalidation response; receiving an HTTP validation request for theembedded resource, the HTTP validation request being issued by the webbrowser after receiving the validation response; and sending thevalidation response to the client system to provide the validationresponse to the web browser rendering the web page to satisfy the HTTPvalidation request issued by the web browser to validate the embeddedresource.
 28. The method of claim 27, wherein the validation message isgenerated, at the client system, based on a page structure correspondingto the web page and identifying the embedded resource.
 29. The method ofclaim 28, wherein the page structure includes a cache characteristic ofthe embedded resource.
 30. The method of claim 29, wherein the cachecharacteristic of the embedded resource includes an indicator specifyinga time when the embedded resource becomes out dated.
 31. The method ofclaim 27, wherein the validation message identifies the embeddedresource by indicating a URL for the embedded resource.
 32. The methodof claim 27, wherein receiving the validation message comprisesreceiving the validation message at a traffic server of an Internetservice provider and receiving the validation response comprisesreceiving the validation response at the traffic server.
 33. The methodof claim 27 further comprising: receiving multiple validation messagesfrom one or more client systems, the multiple validation messagesidentifying embedded resources in the web page; generating an aggregatepage structure by determining which one of the multiple validationmessages was most recently received; and determining to send the requestto validate the embedded resource based on a union of the aggregate pagestructure and the validation message sent by the client system.
 34. Themethod of claim 27 further comprising: receiving multiple validationmessages from one or more client systems, the multiple validationmessages identifying embedded resources in the web page; generating anaggregate page structure by determining common embedded resources amongthe multiple validation messages; and prioritizing the request tovalidate the embedded resource based on the validation message sent bythe client system and the aggregate page structure.
 35. The method ofclaim 28, wherein the page structure is generated based, at least inpart, on an initial validation response to an initial request for theembedded resource during an initial rendering of the web page.
 36. Themethod of claim 28, wherein the page structure is updated at the clientsystem based, at least in part, on the validation response.
 37. A systemfor validating cached embedded resources in a web page comprising: amemory device that stores instructions; and one or more processors thatare configured to execute the instructions to: receive a validationmessage from a client system executing a web browser, the validationmessage identifying at least one resource embedded in a web page andstored in a cache of the web browser, the validation message being sentby the client system prior to the web browser issuing an HTTP validationrequest for the embedded resource; send, to a server, a request tovalidate the embedded resource to determine whether the embeddedresource has been modified since the embedded resource was stored in thecache of the web browser; receive, in response to the request sent tothe server, a validation response; receive an HTTP validation requestfor the embedded resource, the HTTP validation request being issued bythe web browser after receiving the validation response; and send thevalidation response to the client system to provide the validationresponse to the web browser rendering the web page to satisfy the HTTPvalidation request issued by the web browser to validate the embeddedresource.
 38. The system of claim 37, wherein the validation message isgenerated, at the client system, based on a page structure correspondingto the web page and identifying the embedded resource.
 39. The system ofclaim 38, wherein the page structure includes a cache characteristic ofthe embedded resource.
 40. The system of claim 39, wherein the cachecharacteristic of the embedded resource includes an indicator specifyinga time when the embedded resource becomes out dated.
 41. The system ofclaim 37, wherein the validation message identifies the embeddedresource by indicating a URL for the embedded resource.
 42. The systemof claim 37, wherein the instructions are further executed by the one ormore processors to: receive multiple validation messages from one ormore client systems, the multiple validation messages identifyingembedded resources in the web page; generate an aggregate page structureby determining which one of the multiple validation messages was mostrecently received; and determine to send the request to validate theembedded resource based on a union of the aggregate page structure andthe validation message sent by the client system.
 43. The system ofclaim 37, wherein the instructions are further executed by the one ormore processors to: receive multiple validation messages from one ormore client systems, the multiple validation messages identifyingembedded resources in the web page; generate an aggregate page structureby determining common embedded resources among the multiple validationmessages; and prioritize the request to validate the embedded resourcebased on the validation message sent by the client system and theaggregate page structure.
 44. The system of claim 38, wherein the pagestructure is generated based, at least in part, on an initial validationresponse to an initial request for the embedded resource during aninitial rendering of the web page.
 45. The method of claim 28, whereinthe page structure is updated at the client system based, at least inpart, on the validation response.
 46. A non-transitory computer readablemedium embodying a computer program product, the computer programproduct comprising instructions configured to cause a computing deviceto: receive a validation message from a client system executing a webbrowser, the validation message identifying at least one resourceembedded in a web page and stored in a cache of the web browser, thevalidation message being sent by the client system prior to the webbrowser issuing an HTTP validation request for the embedded resource;send, to a server, a request to validate the embedded resource todetermine whether the embedded resource has been modified since theembedded resource was stored in the cache of the web browser; receive,in response to the request sent to the server, a validation response;receive an HTTP validation request for the embedded resource, the HTTPvalidation request being issued by the web browser after receiving thevalidation response; and send the validation response to the clientsystem to provide the validation response to the web browser renderingthe web page to satisfy the HTTP validation request issued by the webbrowser to validate the embedded resource.